Transparent access of STB MHP digital TV middleware to IP video content

ABSTRACT

The invention relates to a set-top box receiver allowing access to interactive digital TV coming from any IP-network. It makes use of the SAP/SDP protocols as a logic link between “classic” DVB services (satellite, terrestrial, cable) and IP services. The invention allows providing TV services relying on existing Internet architecture. Simulation means are provided, in the MHP middleware, for building an Event Information Table upon the SDP messages. Specific preview information is added to the SDP messages so that they can be linked to a DVB service.

FIELD OF THE INVENTION

The invention relates to Digital Video Broadcasting (DVB) television.More particularly, it relates to a receiver for receiving digitalinteractive content provided on predefined service channels from atleast a digital content provider, said content comprising eventinformation data including data about programs, denoted events, whichare provided by said content provider on said predefined servicechannels, the receiver comprising program guide means associated withdisplay means for browsing said event information data and deriving alist of said service channels and their associated events to bedisplayed on said display means.

The invention also relates to an interactive digital video systemcomprising such a receiver.

BACKGROUND ART

The current DVB Digital television standard defines broadcast of audio,video and additional data on a stream. From this additional content, theinteractive digital TV middleware MHP (Multimedia Home Platform) is ableto extract several tables defined by the DVB SI (Section Information)standard relating to signaling information. Amongst these tables, theEvent Information Table (EIT) contains data about the Events (theprograms) broadcast on a specific Service (the channel). These data canthen be browsed by means of specific software, called an ElectronicProgram Guide (EPG), which displays a list of Services (the channels)and their associated Events (the programs). However, the end-user islimited to browsing data coming from the stream only (that is aterrestrial, satellite or cable signal) and from no other source.

The DVB SI norm states that the EIT provides, amongst others, the nameof the event, the start time of the event, the duration of the event, alocator, which is special information for the receiver (the Set Top Boxor STB) to tune to the right Service.

Future developments of digital TV will probably provide severalcomplementary sources linked to an Event: genuine DVB MPEG2 (MovingPicture Expert Group 2) streamed data (broadcast on a satellite,terrestrial or cable signal) and, for instance, an additional MPEG4(Moving Picture Expert Group 4) preview stream coming from the Internet.

For such an application (MPEG4 preview stream coming from the Internet),the SDP/SAP protocols (Service Description Protocol/Service AnnouncementProtocol) seem to suit well, for they are designed to allowparticipation to multimedia conferences on the Internet. An end-useruses the SAP to register to an MPEG4 video announcer and is notified ofthe parameters of the video session thanks to the SDP. Therefore, theuser needs several parameters, such as the name of the video, the startand end time of the video, the IP address of the MPEG4 video server andthe number of the port on which the video is played.

Watching an SDP/SAP Internet-distributed MPEG4 preview of a broadcastMPEG2 Event would impose the merging of the SDP/SAP information (IPaddress and port) with the genuine DVB SI Event data, while complyingwith the DVB SI standard (and the EIT structure).

OBJECT AND SUMMARY OF THE INVENTION

It is an object of the invention to allow the user to use data providedby the DVB SI Event Information Table to access IP (InternetProtocol)-streamed video. An Event is proposed to the end-user, withwhich Event at least two sources are associated and the system has toprovide a way to transparently access any of the sources.

In accordance with the invention, a receiver as mentioned in the openingparagraph is provided, wherein the receiver comprises serviceinformation means allowing use of said event information data to accessIP (Internet Protocol)-streamed video content services, said serviceinformation means comprising the use of SAP/SDP (Service AnnouncementProtocol/Service Description Protocol) as a link between the servicechannels provided by said digital content provider and said IP-streamedservices.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention and additional features, which may be optionally used toimplement the invention, are apparent from and will be elucidated withreference to the drawings described hereinafter and wherein:

FIG. 1 is a functional block diagram for illustrating thefunctionalities of a receiver in accordance with the invention,

FIG. 2 is a functional block diagram illustrating an example of a systemin accordance with the invention.

DETAILED DESCRIPTION OF THE DRAWINGS

A problem solved by the invention is to allow a Set Top Box receiver toaccess interactive digital Television (TV) coming from any IP (InternetProtocol) network. It would allow small to medium-sized companies toprovide TV services without requiring purchase of costly licenses andwithout the heavy infrastructure of a broadcaster, relying on existingInternet architecture. A solution lies in simulating in the MHPmiddleware an Event Information Table built upon the SDP messages.

To achieve such a result, specific “preview information” is added to theSDP messages, so that they can be linked to a DVB Service. It isproposed to add these fields to the structure of a SDP message:

-   -   locator DvbLocator    -   int eventID        Given that a SDP message provides the following useful data:    -   start time of the Session    -   end time of the Session    -   IP address and port of the video server    -   a session ID and revision ID which ensure the capability to        generate a unique Event ID on the IP address and port (as DVB SI        requires a unique Event ID on a Service).

A DVB Event is uniquely defined by the key (DvbLocator, EventID). Thanksto this information, the MHP middleware will be able to match a SDPmessage with a DVB Event, and then get the MPEG4 IP preview video linkedto the MPEG2 broadcast Event.

A switching mechanism inside the MHP middleware is introduced to relayrequest for EIT to primary and secondary sources. Assuming that thesystem provides access to two sources:

-   -   a primary source (with a regular Network Interface detected by        the system), which Services are installed as specified by MHP;    -   a secondary source, which provides only Events linked to the        Events of the primary source.

The system can be divided into three layers, as shown in FIG. 1. FIG. 1shows a multiple-source MHP receiver comprising an Application Layer ALconsisting of an electronic Program Guide EPG, a Middleware Layer,consisting of the Multimedia Home Platform MHP, a Primary source denotedBS consisting of Broadcast streams and a secondary source, denotedSDP/SAP, consisting of the IP-stream.

The proposed algorithm comprises the following 6 steps, indicated byreference numerals in FIG. 1:

-   1) The Application has a Service and its corresponding DvbLocator,    defined by the Primary Source (it is installed at the startup of the    system and located on the Network Interface of the Primary Source).    The Application wants to retrieve an Event associated with this    Service. It makes the request to the MHP middleware (step 1 in FIG.    1).-   2) The MHP middleware requests for the Service to the Primary Source    (step 2).-   3) The Primary Source sends back the Event data to the middleware    (step 3).-   4) The MHP middleware extracts the unique Event ID from the Event    and sends a request to the Secondary Source (SDP/SAP) for additional    information concerning the Event uniquely identified by the key    (DvbLocator, Event ID) (step 4).-   5) The Secondary Source sends back its additional Event information    to the middleware (step 5).-   6) The MHP middleware merges the genuine data sent by the Primary    Source with the additional information of the Secondary Source. It    adds a specific private Descriptor to the content of the Event. This    specific Descriptor is information that can be used to signal the    presence of extended information in the Event. The middleware then    sends back the result to the Application (step 6).

The Application receives the Event, and by scanning the list ofDescriptors can determine if additional information is embedded in theEvent, and extract it to play video from the Internet, for instance.

This invention allows transparent access to video applications, eitherfrom a “classic” source or from an IP network (LAN or Internet). A majorapplication is the navigation amongst Events in a SDP/SAP source. In theexplanation of the realization of the system, the SDP/SAP Source isenslaved to a Primary Source because its services are not installed(that is, they rely on other Services to be displayed and opened to theend-user customer). If SAP/SDP is used as a Primary Source, i.e. isrecognized by the system as a fully independent Network Interface andits Services are installed, then the innovation can be extended toretrieve specific Events amongst the SDP/SAP Services.

The DVB SI norm defines three kinds of Events for a given Service:

-   -   the Present Event, which is the currently broadcast Event;    -   the Following Event, which is the next Event to come;    -   Scheduled Events, which are a set of Events (for instance, all        the Events within the next 7 days).

The MHP middleware provides an API to retrieve information about thesePresent, Following and Scheduled Events. The Event data are sentcontinuously in a loop in the broadcast stream. The middleware canextract the right requested Events because each Event broadcast in thestream conveys additional information about its type (Present,Following, Scheduled).

The problem is to propose a similar behavior from a SDP/SAP source. SAPdoes not provide the same looping retransmission mechanism as abroadcast stream, and “pure” SDP messages do not have the notion of“Present”, “Following” or “Scheduled”. For the coming mechanism, weassume that a Service matches in a unique way a pair (IP address, port):all the programs of an IP-video channel come from the same server at thesame port.

At the startup of the system, the middleware receives several SDPmessages, each one describing an Event (that is, amongst otherinformation, the start and end time of the Event, and the IP address andport of the server that plays the video). MHP can then build a Table ofServices based upon the pairs of (IP address, port) conveyed in theEvent information (that is the SDP messages). It is then able to presenta list of Services to the end-user.

If the middleware has to retrieve information about the Present Event ofa Service, it looks for the SDP message which has the followingcharacteristics:

-   -   the pair (IP address, port) matches the pair of the Service as        extracted from the Table of Services;    -   the start time of the Event is anterior to the current time of        the system;    -   the end time of the Event is posterior to the current time of        the system.

If the middleware has to retrieve information about the Following Eventof a Service, it looks for the SDP message which has the followingcharacteristics:

-   -   the pair (IP address, port) matches the pair of the Service as        extracted from the Table of Services;    -   the start time of the Event is the nearest after the end time of        the Present Event amongst all start times of the Events of the        Service identified by the pair (IP address, port) (note that the        start time of the Following Event may be equal to the end time        of the Present Event).

If the middleware is requested for the Scheduled Events of a Servicebroadcast within a given time period (defined by a start time and an endtime), it looks for the SDP messages which have the followingcharacteristics:

-   -   the start time of the Events is posterior to the start time of        the period and anterior to the end time of the period.

This invention allows a STB to access interactive digital TV coming fromany IP-network. It would allow small to medium-sized companies toprovide TV services without requiring purchase of costly licenses andwithout the heavy infrastructure of a broadcaster, relying on existingInternet architecture.

FIG. 2 shows the architecture of a system in accordance with theinvention for allowing convergence of IP video and broadcast video on aSet Top Box receiver. The system comprises a receiver STB, for receivingvideo content, a broadcast video service provider SP, an Internetnetwork IP, a video server VS and an Announces Server SAP/SDP.

The implementation of the middleware running on the STB is modified toextract its Event information not only from the broadcast MPEG2 streambut also from the SDP/SAP server. The latter sends back informationabout the videos that could be streamed by the MPEG4 video server.Specific EPG software, running on the STB, is able to extract those datafrom the EIT and pass them on to a MPEG4 video player software.

This invention allows transparent access to video applications, eitherfrom a “classic” source or from an IP network (LAN or internet).

1. An end-user receiver for receiving digital interactive contentprovided on predefined service channels from at least a digital videocontent provider, said content comprising event information dataincluding data about programs, denoted events, which are provided bysaid digital video content provider on said predefined service channels,the receiver comprising program guide means associated with displaymeans for browsing said event information data and deriving a list ofsaid service channels and their associated events to be displayed onsaid display means, wherein the end-user receiver further comprisesservice information means allowing use of said event information data toaccess IP (Internet Protocol)-streamed video content services via anInternet connection separate from said predefined service channels, saidservice information means comprising the use of SAP/SDP (ServiceAnnouncement Protocol/Service Description Protocol) as a link betweenthe service channels provided by said digital video content provider andsaid IP-streamed services.
 2. The end-user receiver as claimed in claim1, wherein said service information means comprise simulation means forsimulating said event information data built upon said SDP messages. 3.The end-user receiver as claimed in claim 2, wherein said simulationmeans include means for adding specific preview information to said SDPmessages so that they can be linked to a service channel provided bysaid digital video content provider, denoted DVB service.
 4. Theend-user receiver as claimed in claim 3, wherein said specific previewinformation includes a key comprising a first field, denoted DVBLocator, for locating said DVB service and a second field, denoted EventID for identifying the event associated with said DVB service, an eventbeing uniquely defined by said key (DVB locator, Event ID).
 5. Aninteractive digital video system comprising, at least, a digital videocontent provider for broadcasting DVB (Digital Video Broadcasting)content, an IP (Internet Protocol) network for providing IP-streamedvideo content and an end-user receiver having access to both broadcastand IP-streamed video content, wherein the end-user receiver is anend-user receiver as claimed in claim 1.